In modern business environments there is often a situation found in which an end-user does some business relevant work on a so-called client computer which is connected to one or more dedicated server computers, as e.g., a file server, a database server in a heterogenous network comprising PC, workstation and mainframe computers.
In particular, when data is sent from the client to one predefined server over the network the transfer is called a ‘request’ to said server for getting some data back. Or, when the client-requested data is sent back from the server to the client the transfer is called a ‘response’. In this manner traffic is generated in the network. The data is usually sent ‘wrapped’ in packets, the regular packet size being dependent of the actual network protocol in use. The packets are routed through the network driven by the computing resources of the router computers.
A considerable portion of working time, however, is waisted when the end-user has to wait too long until he receives the requested data back from the server. When more than one, e.g., 20 serial request/response pairs result from only one user-initiated unit of work, transaction, etc., then, those 20 requests must be completed in order to terminate the end-user's waiting period. In such a case any additional network delay, e.g., because of network problems, is amplified by this factor, e.g. 20, so even small additional network delays in the milliseconds range can easily add up to time ranges visible to the end user.
In the case of batch workloads, there are often millions of serial request/response pairs in a single batch job, so that this effect may have dramatic dimensions.
Thus, it is a general task to observe the speed of traffic in the network and to realize quickly when there are network performance problems which yield to such waste of time. Then, any measure can be undertaken in order to solve the underlying technical problem.
A prior art approach for doing this task is a piece of software, one part of it being installed as a middleware program at the server side, and the counterpart being installed at the client side. It is the network statistics function of the currently delivered ICLI component of OS/390, described in the IBM book “SAP R/3 on DB2 for OS/390: Planning Guide, SAP R/3 Release 4.6A”, SC33-7964-01, published September 1999 (which is hereby incorporated herein by reference in its entirety), the basic way of operation of which is illustrated with reference to FIG. 1.
The client time scale is depicted with the left arrow and the server time scale with the right arrow. Both clocks have an undefined time lag as—in most cases they are not synchronized—which is not depicted in the drawing. Said time lag can be considered as quasi-constant because the long time variation of the time lag can in most cases be neglected.
At the client time T1 the client sends a request to the server. Said request is received at server time U2 at the server. Then the request is processed during a duration Ds and is sent back to the client at server time U3. Thus, the server processing time Ds is Ds=U3−U2. Then, the response data is receceived at the client side at the client time T4. Thus, the client program ‘sees’ a time difference of T4−T1 which it has to wait until it receives the desired response. Said total time difference splits up in three portions: Dq+Ds+Dp.
The server (processing) time Ds spent on the server side is sent back to the client as a part of the response data. The client subtracts the server time Ds from the time it observes between having sent the request data—T1—and having received the response data—T4. The result is the total time D spent in the network, or in other words, the total of request time Dq and response time Dp.
The network time is then used to apply some statistics to it, but this is not of primary interest with respect to the present inventional disclosure.
Realistic, just examplarily given values are as follows:D=Dq+Dp=0.8 . . . 3 msecDs=2 . . . 200 msec.
In case of network performance problems, either Dq or Dp or both could be enlarged significantly, there were observed values of 200 msec for instance.
A disadvantage of this prior art approach is that it is not precise enough as only the total of request time Dq and response time Dp can be used for diagnosing the network traffic problems. Such problems may occur just during the transfer from client to server or just from server to client. Knowing request and response times separately would help in identifying where a performance problem comes from.